package com.example.performance.jmh.official;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;
import org.openjdk.jmh.runner.options.TimeValue;

import java.util.concurrent.TimeUnit;


@SuppressWarnings({"java:S101", "java:S100"})
@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class JMHSample_17_SyncIterations {

    /*
     * This is the another thing that is enabled in JMH by default.
     * <p>
     * Suppose we have this simple benchmark.
     */

    private double src;

    @Benchmark
    public double test() {
        double s = src;
        for (int i = 0; i < 1000; i++) {
            s = Math.sin(s);
        }
        return s;
    }

    /*
     * It turns out if you run the benchmark with multiple threads,
     * the way you start and stop the worker threads seriously affects performance.
     *
     * The natural way would be to park all the threads on some sort of barrier,
     * and the let them go "at once".
     * However, that does not work:
     * there are no guarantees the worker threads will start at the same time,
     * meaning other worker threads are working in better conditions, skewing the result.
     *
     * The better solution would be to introduce bogus iterations,
     * ramp up the threads executing the iterations,
     * and then atomically shift the system to measuring stuff.
     * The same thing can be done during the rampdown.
     * This sounds complicated, but JMH already handles that for you.
     */

    /**
     * ============================== HOW TO RUN THIS TEST: ====================================
     * <p>
     * You will need to oversubscribe the system to make this effect clearly visible;
     * however, this effect can also be shown on the unsaturated systems.
     * <p>
     * Note the performance of -si false version is more flaky, even though it is "better".
     * This is the false improvement, granted by some of the threads executing in solo.
     * The -si true version more stable and coherent.
     * <p>
     * -si true is enabled by default.
     * <p>
     * Say, $CPU is the number of CPUs on your machine.
     * <p>
     * You can run this test with:
     * <p>
     * a) Via the command line:
     *    $ mvn clean install
     *    $ java -jar target/benchmarks.jar JMHSample_17 \
     *        -w 1s -r 1s -f 1 -t ${CPU*16} -si {true|false}
     *    (we requested shorter warmup/measurement iterations, single fork,
     *     lots of threads, and changeable "synchronize iterations" option)
     * <p>
     * b) Via the Java API:
     *    (see the JMH homepage for possible caveats when running from IDE:
     *      <a href="http://openjdk.java.net/projects/code-tools/jmh/">...</a>)
     */

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(JMHSample_17_SyncIterations.class.getSimpleName())
                .warmupTime(TimeValue.seconds(1))
                .measurementTime(TimeValue.seconds(1))
                .threads(Runtime.getRuntime().availableProcessors()*16)
                .forks(1)
                .syncIterations(true) // try to switch to "false"
                .build();

        new Runner(opt).run();
    }

}
